home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pppext-x25-02.txt < prev    next >
Text File  |  1993-10-07  |  15KB  |  552 lines
  1.  
  2.  
  3. Network Working Group                                        W A Simpson
  4. Internet Draft                                                Daydreamer
  5. expires in six months                                       October 1993
  6.  
  7.  
  8.                               PPP in X.25
  9.                       draft-ietf-pppext-x25-02.txt
  10.  
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is the product of the Point-to-Point Protocol Working
  16.    Group of the Internet Engineering Task Force (IETF).  Comments should
  17.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  18.  
  19.    Distribution of this memo is unlimited.
  20.  
  21.    This document is an Internet Draft.  Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups.  Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time.  It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a
  30.    ``working draft'' or ``work in progress.''
  31.  
  32.    Please check the 1id-abstracts.txt listing contained in the
  33.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  34.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  35.    current status of any Internet Draft.
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Simpson                  expires in six months                  [Page i]
  55. DRAFT                         PPP in X.25                   October 1993
  56.  
  57.  
  58. Abstract
  59.  
  60.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  61.    transporting multi-protocol datagrams over point-to-point links.
  62.  
  63.    This document describes the use of X.25 for framing PPP encapsulated
  64.    packets.
  65.  
  66.  
  67. Applicability
  68.  
  69.    This specification is intended for those implementations which desire
  70.    to use facilities which are defined for PPP, such as the Link Control
  71.    Protocol, Network-layer Control Protocols, authentication, and
  72.    compression.  These capabilities require a point-to-point
  73.    relationship between peers, and are not designed for multi-point or
  74.    multi-access environments.
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Simpson                  expires in six months                 [Page ii]
  110. DRAFT                         PPP in X.25                   October 1993
  111.  
  112.  
  113. 1.  Introduction
  114.  
  115.    CCITT recommendation X.25 [2] describes a network layer protocol
  116.    providing error-free, sequenced, flow controlled, virtual circuits.
  117.    X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
  118.    and 6256.
  119.  
  120.    PPP also uses ISO 3309 HDLC as a basis for its framing [3].
  121.  
  122.    When X.25 is configured as a point-to-point circuit, PPP can use X.25
  123.    as a framing mechanism, ignoring its other features.  This is
  124.    equivalent to the technique used to carry SNAP headers over X.25 [4].
  125.  
  126.    At one time, it had been hoped that PPP HDLC frames and X.25 frames
  127.    would co-exist on the same links.  Equipment could gradually be
  128.    converted to PPP.  Subsequently, it has been learned that some
  129.    switches actually remove the X.25 header, transport packets to
  130.    another switch using a different protocol such as Frame Relay, and
  131.    reconstruct the X.25 header at the final hop.  Co-existance and
  132.    gradual migration are precluded.
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Simpson                  expires in six months                  [Page 1]
  165. DRAFT                         PPP in X.25                   October 1993
  166.  
  167.  
  168. 2.  Physical Layer Requirements
  169.  
  170.    PPP treats X.25 framing as a bit synchronous link.  The link MUST be
  171.    full-duplex, but MAY be either dedicated (permanent) or switched.
  172.  
  173.    Interface Format
  174.  
  175.       PPP presents an octet interface to the physical layer.  There is
  176.       no provision for sub-octets to be supplied or accepted.
  177.  
  178.    Transmission Rate
  179.  
  180.       PPP does not impose any restrictions regarding transmission rate,
  181.       other than that of the particular X.25 interface.
  182.  
  183.    Control Signals
  184.  
  185.       Implementation of X.25 requires the provision of control signals,
  186.       which indicate when the link has become connected or disconnected.
  187.       These in turn provide the Up and Down events to the LCP state
  188.       machine.
  189.  
  190.       Because PPP does not normally require the use of control signals,
  191.       the failure of such signals MUST NOT affect correct operation of
  192.       PPP.  Implications are discussed in [2].
  193.  
  194.    Encoding
  195.  
  196.       The definition of various encodings is the responsibility of the
  197.       DTE/DCE equipment in use, and is outside the scope of this
  198.       specification.
  199.  
  200.       While PPP will operate without regard to the underlying
  201.       representation of the bit stream, X.25 requires NRZ encoding.
  202.  
  203.  
  204. 3.  The Data Link Layer
  205.  
  206.    This specification uses the principles, terminology, and frame
  207.    structure described in "Multiprotocol Interconnect on X.25 and ISDN
  208.    in the Packet Mode" [4].
  209.  
  210.    The purpose of this specification is not to document what is already
  211.    standardized in [4].  Instead, this document attempts to give a
  212.    concise summary and point out specific options and features used by
  213.    PPP.
  214.  
  215.  
  216.  
  217.  
  218.  
  219. Simpson                  expires in six months                  [Page 2]
  220. DRAFT                         PPP in X.25                   October 1993
  221.  
  222.  
  223. 3.1.  Frame Format
  224.  
  225.    Since both "PPP in HDLC Framing" [3] and X.25 use ISO 3309 as a basis
  226.    for framing, the X.25 header is easily substituted for the smaller
  227.    HDLC header.  The fields are transmitted from left to right.
  228.  
  229.     0                   1                   2                   3
  230.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  231.    +-+-+-+-+-+-+-+-+
  232.    |  Flag (0x7e)  |
  233.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  234.    |    Address    |    Control    |D|Q| SVC# (hi) |   SVC# (lo)   |
  235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.    |p(r) |M|p(s) |0|         PPP Protocol          |
  237.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.  
  239.    The PPP Protocol field and the following Information and Padding
  240.    fields are described in the Point-to-Point Protocol Encapsulation
  241.    [1].
  242.  
  243.  
  244. 3.2.  Modification of the Basic Frame
  245.  
  246.    The Link Control Protocol can negotiate modifications to the basic
  247.    frame structure.  However, modified frames will always be clearly
  248.    distinguishable from standard frames.
  249.  
  250.    Address-and-Control-Field-Compression
  251.  
  252.       Because the Address and Control field values are not constant, and
  253.       are modified as the frame is transported by the network switching
  254.       fabric, Address-and-Control-Field-Compression MUST NOT be
  255.       negotiated.
  256.  
  257.    Protocol-Field-Compression
  258.  
  259.       Note that unlike the HDLC framing, the X.25 framing does not align
  260.       the Information field on a 32-bit boundary.  Alignment to a 16-bit
  261.       boundary occurs when the Protocol field is compressed to a single
  262.       octet.  When this improves throughput, Protocol-Field-Compression
  263.       SHOULD be negotiated.
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274. Simpson                  expires in six months                  [Page 3]
  275. DRAFT                         PPP in X.25                   October 1993
  276.  
  277.  
  278. 4.  Call Setup
  279.  
  280.    When the link is configured as a Permanent Virtual Circuit (PVC),
  281.    support for Switched Virtual Circuit (SVC) call setup and clearing is
  282.    not required.  Calls are Established and Terminated using PPP LCP
  283.    packets.
  284.  
  285.    When the link is configured as a Switched Virtual Circuit (SVC), the
  286.    first octet in the Call User Data (CUD) Field (the first data octet
  287.    in the Call Request packet) is used for protocol demultiplexing, in
  288.    accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC
  289.    TR 9577 [5].  This field contains a one octet Network Layer Protocol
  290.    Identifier (NLPID), which identifies the encapsulation in use over
  291.    the X.25 virtual circuit.  The CUD field MAY contain more than one
  292.    octet of information.
  293.  
  294.    The PPP encapsulation MUST be indicated by the PPP NLPID value (CF
  295.    hex).  Any subsequent octet in this CUD is extraneous and MUST be
  296.    ignored.
  297.  
  298.    Multipoint networks (or multicast groups) MUST refuse calls which
  299.    indicate the PPP NLPID in the CUD.
  300.  
  301.    The accidental connection of a link to feed a multipoint network (or
  302.    multicast group) SHOULD result in a misconfiguration indication.
  303.    This can be detected by multiple responses to the LCP Configure-
  304.    Request with the same Identifier, coming from different framing
  305.    addresses.  Some implementations might be physically unable to either
  306.    log or report such information.
  307.  
  308.    Conformance with this specification requires that the PPP NLPID (CF)
  309.    be supported.  In addition, conformance with [4] requires that the IP
  310.    NLPID (CC) be supported, and does not require that other NLPID values
  311.    be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS (82).
  312.  
  313.    When IP address negotiation and/or VJ header compression are desired,
  314.    the PPP call setup SHOULD be attempted first.  If the PPP call setup
  315.    fails, the normal IP call setup MUST be used.
  316.  
  317.    The PPP NLPID value SHOULD NOT be used to demultiplex circuits which
  318.    use the Zero NLPID in call setup, as described in [4].  When such a
  319.    circuit exists concurrently with PPP encapsulated circuits, only
  320.    network layer traffic which has not been negotiated by the associated
  321.    NCP is sent over the Zero NLPID circuit.
  322.  
  323.    Rationale:
  324.  
  325.       Using call setup to determine if PPP is supported should be
  326.  
  327.  
  328.  
  329. Simpson                  expires in six months                  [Page 4]
  330. DRAFT                         PPP in X.25                   October 1993
  331.  
  332.  
  333.       inexpensive, when users aren't charged for failed calls.
  334.  
  335.       Using the Zero NLPID call together with PPP could be expensive,
  336.       when users are charged per packet or for connect time, due to the
  337.       probing of PPP configuration packets at each call.
  338.  
  339.       PPP configuration provides a direct indication of the availability
  340.       of service, and on that basis is preferred over the Zero NLPID
  341.       technique, which can result in "black-holes".
  342.  
  343.  
  344. 5.  Configuration Details
  345.  
  346.    The following Configuration Options are recommended:
  347.  
  348.       Magic Number
  349.       Protocol Field Compression
  350.  
  351.    The standard LCP configuration defaults apply to X.25 links, except
  352.    MRU.
  353.  
  354.    To ensure interoperability with existing X.25 implementations, the
  355.    initial Maximum-Receive-Unit (MRU) is 1600 octets [4].  This only
  356.    affects the minimum required buffer space available for receiving
  357.    packets, not the size of packets sent.
  358.  
  359.    The typical network feeding the link is likely to have a MRU of
  360.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  361.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  362.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  363.    negotiated.
  364.  
  365.    The X.25 packet size is not directly related to the MRU.  Instead,
  366.    Protocol Data Units (PDUs) are sent as X.25 "complete packet
  367.    sequences".  That is, PDUs begin on X.25 data packet boundaries and
  368.    the M bit ("more data") is used to fragment PDUs that are larger than
  369.    one X.25 data packet in length.
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384. Simpson                  expires in six months                  [Page 5]
  385. DRAFT                         PPP in X.25                   October 1993
  386.  
  387.  
  388. Security Considerations
  389.  
  390.    Implementations MUST NOT consider PPP authentication on call setup
  391.    for one circuit between two systems to apply to concurrent call setup
  392.    for other circuits between those same two systems.  This results in
  393.    possible security lapses due to over-reliance on the integrity and
  394.    security of switching systems and administrations.  An insertion
  395.    attack might be undetected.  An attacker which is able to spoof the
  396.    same calling identity might be able to avoid link authentication.
  397.  
  398.  
  399. References
  400.  
  401.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
  402.          progress.
  403.  
  404.    [2]   CCITT Recommendation X.25, "Interface Between Data Terminal
  405.          Equipment (DTE) and Data Circuit Terminating Equipment (DCE)
  406.          for Terminals Operating in the Packet Mode on Public Data
  407.          Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
  408.  
  409.    [3]   Simpson, W. A., "PPP in HDLC Framing", work in progress.
  410.  
  411.    [4]   Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect
  412.          on X.25 and ISDN in the Packet Mode", RFC 1356, August 1992.
  413.  
  414.    [5]   ISO/IEC TR 9577, "Information technology - Telecommunications
  415.          and Information exchange between systems - Protocol
  416.          Identification in the network layer", 1990 (E) 1990-10-15.
  417.  
  418.  
  419. Acknowledgments
  420.  
  421.    This design was inspired by the paper "Parameter Negotiation for the
  422.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  423.    University of California, Berkeley, 1992, unpublished.
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439. Simpson                  expires in six months                  [Page 6]
  440. DRAFT                         PPP in X.25                   October 1993
  441.  
  442.  
  443. Chair's Address
  444.  
  445.    The working group can be contacted via the current chair:
  446.  
  447.       Fred Baker
  448.       Advanced Computer Communications
  449.       315 Bollay Drive
  450.       Santa Barbara, California  93117
  451.  
  452.       EMail: fbaker@acc.com
  453.  
  454.  
  455. Author's Address
  456.  
  457.    Questions about this memo can also be directed to:
  458.  
  459.       William Allen Simpson
  460.       Daydreamer
  461.       Computer Systems Consulting Services
  462.       1384 Fontaine
  463.       Madison Heights, Michigan  48071
  464.  
  465.       EMail: Bill.Simpson@um.cc.umich.edu
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494. Simpson                  expires in six months                  [Page 7]
  495. DRAFT                         PPP in X.25                   October 1993
  496.  
  497.  
  498.                            Table of Contents
  499.  
  500.  
  501.      1.     Introduction ..........................................    1
  502.  
  503.      2.     Physical Layer Requirements ...........................    2
  504.  
  505.      3.     The Data Link Layer ...................................    2
  506.         3.1       Frame Format ....................................    3
  507.         3.2       Modification of the Basic Frame .................    3
  508.  
  509.      4.     Call Setup ............................................    4
  510.  
  511.      5.     Configuration Details .................................    5
  512.  
  513.      SECURITY CONSIDERATIONS ......................................    6
  514.  
  515.      REFERENCES ...................................................    6
  516.  
  517.      ACKNOWLEDGEMENTS .............................................    6
  518.  
  519.      CHAIR'S ADDRESS ..............................................    7
  520.  
  521.      AUTHOR'S ADDRESS .............................................    7
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551. Bill.Simpson@um.cc.umich.edu
  552.